Concurrent authoring session management for declarative document

ABSTRACT

Management of an authoring session in which a declarative document is authored by multiple authoring entities. The declarative document is a computer program that is formed of declarative statements made in a declarative programming language. The management occurs by evaluating incoming requests to engage in various ways in an authoring session. The engagement might include initiating an authoring session, attaching to an existing authoring session, or performing actions (such as read, write, publish, save, share, and so forth). The management uses job tokens that are issued to the multiple authors in a manner that concurrent authoring is possible. Upon receiving the request for engagement in the authoring session, the corresponding job token is evaluated to determine whether the requestor is authored to engage as requested. The engagement is then performed if permitted.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 62/329,098, filed Apr. 28, 2016, which provisionalpatent application is incorporated herein by reference in its entirety.

BACKGROUND

A declarative document is a collection of declarations that representthe logic of a computation rather than describing the lower levelcontrol flow. Because those declaration are often more human-readable,the collection of declarations is often termed a “document” rather thana “program”. Furthermore, the creation of such a document is oftentermed “authoring” rather than “programming”.

Because declarations are more human-readable and intuitive to most humanbeings, more individuals are capable of authoring declarative documentsthan are capable of programming using an imperative or object-orientedlanguage. Accordingly, a declarative authoring experience is distinctfrom a computer programming experience. In a declarative authoringexperience, it seems to the user as though the user is authoring adocument, though after compilation, the document may consist ofcomputer-executable code. The document may be, for instance, be atransformation chain or graph that has associated state. Atransformation chain is an interconnected set of nodes that each mayrepresent data sources or data targets.

The subject matter claimed herein is not limited to embodiments thatsolve any disadvantages or that operate only in environments such asthose described above. Rather, this background is only provided toillustrate one exemplary technology area where some embodimentsdescribed herein may be practiced.

BRIEF SUMMARY

At least some embodiments described herein relate to the management ofan authoring session in which a declarative document is authored bymultiple authoring entities. The declarative document is a computerprogram that is represented as a list of declarative statements made ina declarative programming language. The management occurs by evaluatingincoming requests to engage in various ways in an authoring session. Theengagement might include initiating an authoring session, attaching toan existing authoring session, or performing actions (such as read,write, publish, save, share, and so forth).

The management uses job tokens that are issued to the multiple authorsin a manner that concurrent authoring is possible. For instance, jobtokens that represent non-colliding authorizations are issued withrespect to an authoring session. Upon receiving the request forengagement in the authoring session, the job token also accompanied thatrequest. Upon receiving a request, the corresponding job token isevaluated to determine whether the requestor is authored to engage asrequested. The engagement is then permitted if the engagement isauthorized based on evaluation of the job token.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof, which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 symbolically illustrates an authoring environment in accordancewith the principles described herein, and which includes a variety ofcommunication flows used to accomplish the principles described herein;

FIG. 2 illustrates a computing system in which the principles describedherein may operate;

FIG. 3 illustrates a flowchart of a method for issuing a job token inresponse to a request to engage in an authoring session in which adeclarative document is being authored;

FIG. 4 illustrates a flowchart of a method for managing an authoringsession in which a declarative document is being authored;

FIG. 5 illustrates a session that shows at least all active sessions forwhich there is a document server host running within a back end service;

FIG. 6 shows a user interface which illustrates to the user the versionof a declarative document that will work with a specific device and witha specific version of the application document available on the device;and

FIG. 7 illustrates the user interface that appears should the userselect on version 3 in the user interface of FIG. 6, and in which theuser is given an indication that they can replace the current version ofthe declarative document with the selected version.

DETAILED DESCRIPTION

The principles described herein provide an application authoringenvironment. In some embodiments, the application may generate via adeclarative authoring experience in which it seems to the user as thoughthe user is authoring a document, via higher-level human-readabledeclaration. After compilation, the document may consist ofcomputer-executable code. The document (also called herein a“declarative document”) may be, for instance, a transformation chain orgraph that has associated state. A transformation chain is aninterconnected set of nodes that each may represent data sources or datatargets.

In the case that the declarative document represents a transformationchain or graph, there are links between the nodes, each linkrepresenting a transformation. For any given link, the associatedtransformation receives copies of values of one or more data sourcessituated at an input end to the link, and generates resulting valuesbeing provided at one or more data targets located at the output end ofthe link. For any given transformation, when a value at one or more ofthe data sources at its input end changes, the transformation isautomatically reevaluated, potentially resulting in changes in value(s)of one or more data targets at the output end of the transformation. Therole of nodes and links may of course reverse, with nodes representingdata flows, and links representing transformations.

In one embodiment, regardless of how complex the transformation chainis, the transformations may be constructed from declarative statementsexpressing equations, rules, constraints, simulations, or any othertransformation type that may receive one or more values as input andprovide the resulting one or more values as output. Transformationchains may be augmented as a program is built by linking differenttransformation chains to honor the dependencies between the chains.Portions of transformation chains may also be delegated to other devicesand/or users. Nodes of the transformation graph may encapsulate specificdata included within a given data set/data table (e.g., data includedwithin a data field of a data table), which data may be visualized in agenerated application, as described herein.

One benefit of using a declarative document is that dependencies ofevery document entity are traceable and known, which allows a subset ofthe document to be safely shared. For example, suppose that a singlescreen of an application is shared for edit. If the application isdescribed via a declarative document, the system can trace back everysingle dependency (e.g. controls on other screens, data sources,external functions, and so forth) and apply suitable permissions too.

At least some embodiments described herein relate to the management ofan authoring session in which a declarative document is authored bymultiple authoring entities. The declarative document is a computerprogram that is represented as a list of declarative statements made ina declarative programming language. The management occurs by evaluatingincoming requests to engage in various ways in an authoring session. Theengagement might include initiating an authoring session, attaching toan existing authoring session, or performing actions (such as read,write, publish, save, share, and so forth).

The management uses job tokens that are issued to the multiple authorsin a manner that concurrent authoring is possible. For instance, jobtokens that represent non-colliding authorizations are issued withrespect to an authoring session. Upon receiving the request forengagement in the authoring session, the job token also accompanied thatrequest. Upon receiving a request, the corresponding job token isevaluated to determine whether the requestor is authored to engage asrequested. The engagement is then permitted if the engagement isauthorized based on evaluation of the job token.

FIG. 1 illustrates an authoring environment 100 in accordance with theprinciples described herein. The authoring environment 100 includes anauthoring computing system 110 that communicates with (as represented byarrow 102) an associated user 101. The authoring computing system 110also communicates with an authoring service in order to author adeclarative document. In this description and in the claims, the terms“author” and “document” will be used often in lieu of “coder” and“program” as the program is coded in declarative form and thus may havethe sense of being a document (e.g., a MICROSOFT EXCEL) document, andthe coder is dealing with declarative statements more than imperativecode.

The authoring environment 100 also includes an identity service 120, anauthorization service 130, a token service 140, a session initiationservice 150, a backend service 160, a redistribution service 170, and arequest rerouting service 180. Each of the services 120, 130, 140, 150,160, 170 and 180 may be accessible to multiple users engaging inmultiple sessions on multiple versions of multiple documents. As thecomputing system 110, and each of the various services 120, 130, 140,150, 160, 170 and 180, may be offered by a stand-alone and/ordistributed computing system, a computing system will now be describedwith respect to FIG. 2. Then, the operation of the authoring environment100 will be further described with respect to FIGS. 3 through 5. Then,the implementation of versioning with respect to the authoringenvironment will be described with respect to FIGS. 6 and 7.

Computing systems are now increasingly taking a wide variety of forms.Computing systems may, for example, be handheld devices, appliances,laptop computers, desktop computers, mainframes, distributed computingsystems, datacenters, or even devices that have not conventionally beenconsidered a computing system, such as wearables (e.g., glasses,watches, bands, and so forth). In this description and in the claims,the term “computing system” is defined broadly as including any deviceor system (or combination thereof) that includes at least one physicaland tangible processor, and a physical and tangible memory capable ofhaving thereon computer-executable instructions that may be executed bya processor. The memory may take any form and may depend on the natureand form of the computing system. A computing system may be distributedover a network environment and may include multiple constituentcomputing systems.

As illustrated in FIG. 2, in its most basic configuration, a computingsystem 200 typically includes at least one hardware processing unit 202and memory 204. The memory 204 may be physical system memory, which maybe volatile, non-volatile, or some combination of the two. The term“memory” may also be used herein to refer to non-volatile mass storagesuch as physical storage media. If the computing system is distributed,the processing, memory and/or storage capability may be distributed aswell.

The computing system 200 also has thereon multiple structures oftenreferred to as an “executable component”. For instance, the memory 204of the computing system 200 is illustrated as including executablecomponent 206. The term “executable component” is the name for astructure that is well understood to one of ordinary skill in the art inthe field of computing as being a structure that can be software,hardware, or a combination thereof. For instance, when implemented insoftware, one of ordinary skill in the art would understand that thestructure of an executable component may include software objects,routines, methods that may be executed on the computing system, whethersuch an executable component exists in the heap of a computing system,or whether the executable component exists on computer-readable storagemedia.

In such a case, one of ordinary skill in the art will recognize that thestructure of the executable component exists on a computer-readablemedium such that, when interpreted by one or more processors of acomputing system (e.g., by a processor thread), the computing system iscaused to perform a function. Such structure may be computer-readabledirectly by the processors (as is the case if the executable componentwere binary). Alternatively, the structure may be structured to beinterpretable and/or compiled (whether in a single stage or in multiplestages) so as to generate such binary that is directly interpretable bythe processors. Such an understanding of example structures of anexecutable component is well within the understanding of one of ordinaryskill in the art of computing when using the term “executablecomponent”.

The term “executable component” is also well understood by one ofordinary skill as including structures that are implemented exclusivelyor near-exclusively in hardware, such as within a field programmablegate array (FPGA), an application specific integrated circuit (ASIC), orany other specialized circuit. Accordingly, the term “executablecomponent” is a term for a structure that is well understood by those ofordinary skill in the art of computing, whether implemented in software,hardware, or a combination. In this description, the terms “component”and “service”, or the like may also be used. As used in this descriptionand in the case, these terms (whether expressed with or without amodifying clause) are also intended to be synonymous with the term“executable component”, and thus also have a structure that is wellunderstood by those of ordinary skill in the art of computing.

In the description that follows, embodiments are described withreference to acts that are performed by one or more computing systems.If such acts are implemented in software, one or more processors (of theassociated computing system that performs the act) direct the operationof the computing system in response to having executedcomputer-executable instructions that constitute an executablecomponent. For example, such computer-executable instructions may beembodied on one or more computer-readable media that form a computerprogram product. An example of such an operation involves themanipulation of data.

The computer-executable instructions (and the manipulated data) may bestored in the memory 204 of the computing system 200. Computing system200 may also contain communication channels 208 that allow the computingsystem 200 to communicate with other computing systems over, forexample, network 210.

While not all computing systems require a user interface, in someembodiments, the computing system 200 includes a user interface 212 foruse in interfacing with a user. The user interface 212 may includeoutput mechanisms 212A as well as input mechanisms 212B. The principlesdescribed herein are not limited to the precise output mechanisms 212Aor input mechanisms 212B as such will depend on the nature of thedevice. However, output mechanisms 212A might include, for instance,speakers, displays, projectors, tactile output, valves, actuators,holograms, virtual reality, and so forth. Examples of input mechanisms212B might include, for instance, microphones, touchscreens, holograms,virtual reality controls, cameras, keyboards, accelerometers, levers,pedals, buttons, knobs, mouse of other pointer input, sensors of anytype, and so forth.

Embodiments described herein may comprise or utilize a special purposeor general-purpose computing system including computer hardware, suchas, for example, one or more processors and system memory, as discussedin greater detail below. Embodiments described herein also includephysical and other computer-readable media for carrying or storingcomputer-executable instructions and/or data structures. Suchcomputer-readable media can be any available media that can be accessedby a general purpose or special purpose computing system.Computer-readable media that store computer-executable instructions arephysical storage media. Computer-readable media that carrycomputer-executable instructions are transmission media. Thus, by way ofexample, and not limitation, embodiments of the invention can compriseat least two distinctly different kinds of computer-readable media:storage media and transmission media.

Computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other physical and tangible storage medium whichcan be used to store desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computing system.

A “network” is defined as one or more data links that enable thetransport of electronic data between computing systems and/or modulesand/or other electronic devices. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputing system, the computing system properly views the connection asa transmission medium. Transmissions media can include a network and/ordata links which can be used to carry desired program code means in theform of computer-executable instructions or data structures and whichcan be accessed by a general purpose or special purpose computingsystem. Combinations of the above should also be included within thescope of computer-readable media.

Further, upon reaching various computing system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media to storagemedia (or vice versa). For example, computer-executable instructions ordata structures received over a network or data link can be buffered inRAM within a network interface module (e.g., a “NIC”), and theneventually transferred to computing system RAM and/or to less volatilestorage media at a computing system. Thus, it should be understood thatstorage media can be included in computing system components that also(or even primarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions anddata which, when executed at a processor, cause a general purposecomputing system, special purpose computing system, or special purposeprocessing device to perform a certain function or group of functions.Alternatively or in addition, the computer-executable instructions mayconfigure the computing system to perform a certain function or group offunctions. The computer executable instructions may be, for example,binaries or even instructions that undergo some translation (such ascompilation) before direct execution by the processors, such asintermediate format instructions such as assembly language, or evensource code.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate, after having read thisdescription, that the invention may be practiced in network computingenvironments with many types of computing system configurations,including, personal computers, desktop computers, laptop computers,message processors, hand-held devices, multi-processor systems,microprocessor-based or programmable consumer electronics, network PCs,minicomputers, mainframe computers, mobile telephones, PDAs, pagers,routers, switches, datacenters, wearables (such as glasses) and thelike. The invention may also be practiced in distributed systemenvironments where local and remote computing systems, which are linked(either by hardwired data links, wireless data links, or by acombination of hardwired and wireless data links) through a network,both perform tasks. In a distributed system environment, program modulesmay be located in both local and remote memory storage devices.

Those skilled in the art will also appreciate, after having read thisdescription, that the invention may be practiced in a cloud computingenvironment. Cloud computing environments may be distributed, althoughthis is not required. When distributed, cloud computing environments maybe distributed internationally within an organization and/or havecomponents possessed across multiple organizations. In this descriptionand the following claims, “cloud computing” is defined as a model forenabling on-demand network access to a shared pool of configurablecomputing resources (e.g., networks, servers, storage, applications, andservices). The definition of “cloud computing” is not limited to any ofthe other numerous advantages that can be obtained from such a modelwhen properly deployed.

For instance, cloud computing is currently employed in the marketplaceso as to offer ubiquitous and convenient on-demand access to the sharedpool of configurable computing resources. Furthermore, the shared poolof configurable computing resources can be rapidly provisioned viavirtualization and released with low management effort or serviceprovider interaction, and then scaled accordingly.

A cloud computing model can be composed of various characteristics suchas on-demand self-service, broad network access, resource pooling, rapidelasticity, measured service, and so forth. A cloud computing model mayalso come in the form of various service models such as, for example,Software as a Service (“SaaS”), Platform as a Service (“PaaS”), andInfrastructure as a Service (“IaaS”). The cloud computing model may alsobe deployed using different deployment models such as private cloud,community cloud, public cloud, hybrid cloud, and so forth. In thisdescription and in the claims, a “cloud computing environment” is anenvironment in which cloud computing is employed.

Returning to FIG. 1, the operation of the authoring environment 100 tosecurely start a stateful session for purposes of generating adeclarative document will now be described with respect to FIGS. 1, 3through 5. Thereafter, versioning in the context of the authoring ofdeclarative documents will be described with respect to FIGS. 6 and 7.

A user 101 interfaces (as represented by arrow 102) with an authoringcomputing system 110. The user 101 is a member of a particular identitythat requests to engage in an authoring session to begin and/or continueauthoring of a declarative document. Alternatively, the user 101 is thatparticular entity that requests to engage in the authoring session.

The process of initiating a stateful session in response to such userinteraction will now be described. The user 101 interfaces with theauthoring computing system 110 so as to indicate an intent to initiatean authoring session to thereby author a declaratory document. Theauthoring computing system 110 responds by sending (as represented byarrow 103A) a request for an identity token from an identity service120. The identity token may be used to prove that the possessor thereofis of a particular identity. The identity service 120 responds (asrepresented by arrow 103B) by providing the identity token back to theauthoring computing system 110. As an example, if one or more of theservices of FIG. 1 were hosted within a public cloud computingenvironment, and that public cloud environment were the MICROSOFT®AZURE™ public cloud, then the identity service 120 might be the AZURE™ACTIVE DIRECTORY®.

The authoring computing system 110 then provides (as represented byarrow 104A) that identity token to the token service 140 with a requestto perform a job. The job request represents a request to perform acertain scope of engagement in an authoring session in which thedeclarative document is authored. The token service 140 then, ifappropriate, issues a job token that includes an authorization toperform at least the requested job (which in this cases is to initiatean authoring session).

FIG. 3 illustrates a flowchart of a method 300 for issuing a job token.The method 300 may be performed by the token service 140 each time thetoken service 140 receives a request to perform a job in an authoringsession in which the declarative document is being authored. The methodis initiated upon receiving a particular request to perform a job inthat authoring session (act 301). This receipt is represented by arrow104A of FIG. 1.

For instance, to initiate an authoring session, a request to initiate asession is received by the token service 140. In one embodiment, the jobtoken returned in response to that request describes the full range ofauthorization of the requestor including authorization to initiate theauthoring session, as well as authorization to perform other actions toauthor the declarative document. In other embodiments, the requestormust issue another distinct request to initiate the session, and anotherdistinct request each time the requestor wishes to expand upon thatauthorization (e.g., by continuing in the authoring session).

In order to attach to an existing session that another author initiated,a request to attach to an existing authoring session may be received. Inone embodiment, the job token returned in response to that requestdescribes the full range of authorization of the requestor includingauthorization to attached to the authoring session, as well asauthorization to perform other actions to contribute to authoring thedeclarative document. In other embodiments, the requestor must issueanother distinct request to attached to the session, and anotherdistinct request each time the requestor wishes to expand upon thatauthorization (e.g., by continuing in the authoring session).

Upon receipt of any of such requests, the token service 140 thenidentifies the particular identity that is associated with the request(act 302). As described above, since the request includes the identitytoken issued to the authoring computing system 110 by the identityservice 120 (as represented by arrow 103A), this identification may beperformed by examination of that identity token. However, the principlesdescribed herein are not limited to how the token service 140authenticates the identity associated with the request. The particularidentity might be a single user or a group of users. A user may be humanuser or an artificial intelligence capable of authoring.

The token service 140 then determines an authorization to grant to theparticular identity (act 303). For instance, in FIG. 1, thisauthorization scope was determined via the token service 140 interacting(as represented by arrows 105A and 105B) with the authorization service130. The authorization service 130 may authorize in a manner that forany given authoring session, there are no potentially collidingauthorizations. The token service 140 then constructs an appropriate jobtoken (act 304), and provides that job token to the authoring computingsystem (act 305). For instance, in FIG. 1, arrow 104B represents thisreturning of the job token.

As examples only, the authorization could be directed towards theentirety of the declarative document or an identified portion of thedeclarative document. Alternatively, or in addition, the authorizationmight be defined by the scope of actions allowed. As an example only,such scope might include read authorization allowing the particularidentity to read the declarative document (or a designated portion(s)).Alternatively or in addition, the scope might include an editauthorization which might allow the particular identity to edit thedeclarative document (or a designated portion). Alternatively or inaddition, the scope might include publish authorization allowing theparticular identity to publish the declarative document (or a designatedportion(s)). Alternatively or in addition, the scope might include ashare authorization allowing the particular identity to share at leastone authorization with another identity, and so forth for other possibleauthorization.

The job token also includes a unique session identifier (which may be aglobally unique identifier or “GUID”), as well as other metadata aboutthe session in which the declarative document is being authored. Forinstance, the job token may include an identification of whichapplication documents that the authoring entity may engage in a sessionwith, what the permissions may be (read-only, edit, share), theexpiration period for the identity token, the expiration period for thejob token, renewal terms for the identity token and the job token, andso forth. The job token is signed to allow for detection of tamperingshould the job token be altered. The job token serves as the authoringidentity's passport when submitted subsequent commands related to thesame authoring session.

When initiating a session, the authoring entity then requests (asrepresented by arrow 106) to begin a session to the session initiationservice 150. The session initiation service verifies that the sessioninitiation is authorized by checking the job token that is within therequest. If the verification is successful, the session request isplaced in a predetermined queue that back end systems may draw from tohost authoring sessions. In one example, the queue may take the form ofan AZURE™ queue. For instance, in this example, the back end service 160includes three illustrated back end systems 161 through 163 though theellipses 164 represents that the back end service 160 may include anynumber of back end systems. The back end systems may each be, forinstance, host servers within a cloud computing environment. The backend system 161 may take responsibility for hosting the request sessionas represented by the arrow 107.

To begin loading an associated application document to work on in thesession, a document server host 165 is prepared on the back end system161. The back end system 161 then publishes (as represented by arrow108) to a redistribution service 170 that the document server host 165has taken responsibility for the authoring session. The redistributionservice 170 may have many nodes that are distributed. Accordingly, thearrow 108 represents a publishing process whereby all distributed nodesof the redistribution service 170 are notified that the back end system161 is hosting the authoring session. In a similar manner, theredistribution service 170 may be keeping track of enumerable sessionsby the session identifier GUID, and an associated Internet Protocol (IP)address and port that allows for routing to the appropriate back endsystem that is hosting that session.

When future commands come in related to that session (e.g., from theauthoring computing system or from another user), that command will comeinto (as represented by arrow 111) the request routing service 180 withthe job token provided by the token service 140 for that session. Thatrequest routing service 180 will refer to the nearest redistributionservice 170 (as represented by arrow 112) to identify (as represented byarrow 113) the network address (e.g., the appropriate IP address andport) for the document server host that is handling that session. Thus,the command from the authoring computing system 110 may be passedforward to the appropriate back end system that is hosting the session.For instance, future commands associated with the session being hostedwithin the document server host 165 will be routed (as represented byarrow 114) to the back end system 161 and ultimately to the documentserver host 165.

When the document server host 165 first comes into existence on a backend system, the document server host 165 may perhaps be empty. It is thejob of the document server host 165 (for the duration of the session) toreceive commands from one or more participants in the session. Forinstance, a command might be to load a declarative document beingauthored into the document server host, to edit the declarative documentthat is presently within the document server host, to save thedeclarative document that is presently within the document server host,to remove the declarative document that is presently within the documentserver host, and so forth.

FIG. 4 illustrates a flowchart of a method 400 for managing an authoringsession in which a declarative document is being authored. The method400 is performed each time a request to engage in an authoring sessionis received (act 401). If the request is to initiate an authoringsession, the method 400 may be accomplished by the session initiationservice 150. If the request is to attach to an existing authoringsession, the method 400 may be accomplished by the request routingservice 180 updating the redistribution service 170 to reflectattachment of a new user. If the request is to continue the existingauthoring session by reading or editing the declarative document, themethod 400 may be performed by the document server host 165.

Once receiving the request, the appropriate component determines whetherthe requestor is authorized to engage in the authoring session asrequested (decision block 402). If the user is not authorized based onthis determination (“No” in decision block 402), then the request toengage in the session is declined (act 403). Otherwise, if the user isauthorized based on this determination (“Yes” in decision block 402),then the request is granted (act 404).

For instance, if the request is to initiate an authoring session, ifpermitted by the job token, the session initiation service 150 initiatesthe authoring session by assigning a backend service 160 that therebyestablishes a document server host, which then publishes itself (asrepresented by arrow 108) to the redistribution service 170. If therequest is to attach to an authoring session, if permitted by the jobtoken, the request routing service 180 updates the redistributionservice 170 to reflect the new author. If the request is to edit thedeclarative document by a current author that is already registered inthe session, then the document service host 165 allows the edit ifpermitted by the job token.

There may be a number of versions of the document server host that arepotentially available, each perhaps offering somewhat differentapplication program interfaces for authoring the declarative documentcontained within the document server host. In such a multi-versionedenvironment, it is important that the authoring computing system 110provide the appropriate commands that will be recognized by the versionof the document server host that the authoring computing system expectsto be communicating with. Accordingly, when establishing a secureauthoring session, the authoring computing system may also specify aversion of the document server host that the authoring computing systemis to engage with during the session. This session information iscarried forward throughout establishment of the session and isultimately saved in the redistribution service.

As illustrated in FIG. 5, the redistribution service 170 includes asession table 500 that shows at least all active sessions for whichthere is a document server host running within the back end service 160.There is an entry (e.g., entry 510) for each session. When a command fora session is received by the routing service 180 from the authoringcomputing system 110, the command will include the job token (from whichthe session identifier 501 may be obtained). The command may alsospecify a version of the document server host that the authoringcomputing system expects to deal with. This version is also includedwithin the job token. Accordingly, when the back end server thatestablishes the document server host receives a request for a newsession to be started, the back-end system may load the appropriateversion of the document server host with the appropriate dynamic linklibrary.

In accordance with the principles described herein, concurrent authoringis also enabled. This is done by having multiple job tokens associatedwith a particular session. The first job token associated with a sessionwas obtained and used by the authoring entity (e.g., the authoringcomputing system 110 and/or or user 101). However, a second job token isassociated with an authoring entity that simply wants to participate inthe session (e.g., by reading or editing the document hosted within thedocument server host of the session).

The establishment of the second token may be performed in a similarmanner as the first token was established. The user of an authoringcomputing system requests to attach to an existing session. An identitytoken is obtained from the identity service 120. The authorizationservice 130 then provides authorization for the authenticated entity toattach to a particular session. The token service 140 then generates asigned job token indicating that this second authoring entity hasauthorization to attach to the same session. The second job token is nowthe passport for the second user to participate in the same session asthe first authoring entity. The attachment request is then sent to therouting service 180, which identifies the session and document serverversion based on the second job token, identifies the second user asauthorized to attach to the session, and adds the second job token aspermissible to use the same entry created when processing the firsttoken. The second user is then attached to the session as subsequentcommands from the second user (including the second job token) willcause the commands to be redirected towards the same document serverhost that the first user is engaging with.

A user experience associated with restoring and deleting versions ofdeclarative documents will now be described. Authors and editors ofdeclarative documents have the ability to view all of the previousversions of the declarative document that were ever created. They canpick a specific version to restore which replaces the current version ofthe declarative document\as its latest version. The version count goesup by one and is ordered in a descending order in the user interface.The authors and editors of the resource can also delete older versionsthat are no longer useful.

The History user interface is laid out with all the versions availablein the same view with the options to restore and delete prior versionsfrom the same screen, in a couple of clicks. The users can dorestore/delete just previous versions and not the current version,represented by the representative iconography on the History userinterface screen. After clicking on any of these icons, the user canchoose to proceed with or discard the operation in the in-lineconfirmation, again on the History user interface.

On a specific device, the users will see just the versions that willwork with the specific device and with the version of the applicationdocument available on that device. FIG. 6, for instance, shows a userinterface in which there are five versions of an application documentavailable. For each version, the version date and time are given, alongwith the individual who last made the edit. For prior versions previousto the latest version, an option is given to restore or delete thatversion.

FIG. 7 shows what happens to the user interface when the user selects onversion 3. The user is given an indication that they can replace thecurrent version of the application document with the selected version.The user may cancel the restoration or proceed with the restoration.

In some embodiment, the user may compare and contrast versions of theapplication documents by viewing metadata of the versions (such assharee information and connections associated with the application or byviewing running versions of the application in a new tab), to decidewhich version to restore.

Thus, the principles described herein provide an effective mechanism forauthoring application documents in the context in which there may bemultiple versions of environments (e.g., document server host) that maybe used to author the document, there may be concurrent authoring, andthere may be multiple versions of the document itself). Although thesubject matter has been described in language specific to structuralfeatures and/or methodological acts, it is to be understood that thesubject matter defined in the appended claims is not necessarily limitedto the described features or acts described above, or the order of theacts described above. Rather, the described features and acts aredisclosed as example forms of implementing the claims.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed:
 1. A method for managing an authoring session in whicha declarative document is being authored for compilation into anexecutable application, the method comprising: receiving a plurality ofrequests to engage in an authoring session in which a declarativedocument is authored for compilation into an executable application, atleast some of the requests for engagement being from differentrequestors, the plurality of requests collectively including a pluralityof job tokens that define authorization scope in engaging with thesession in which the declarative document is authored, the plurality ofjob tokens generated so that concurrent authoring of the declarativedocument is achieved in the session without inconsistent activity on thedeclarative document; for at least one request for engagement receivedfrom each different requestor, performing the following: accessing a jobtoken associated with the request for engagement in the session in whichthe declarative document is authored; determining whether the requestoris authorized to engage in the requested engagement based on evaluationof the job token; if the user is not authorized based on thisdetermination, decline the requested engagement in the session in whichthe declarative document is authored; and if the user is authorizedbased on this determination, allowing the requested engagement in thesession in which the declarative document is authored.
 2. The method inaccordance with claim 1, the engagement in the authoring session for afirst requestor being an establishment of the authoring session forauthoring the declarative document.
 3. The method in accordance withclaim 2, the engagement in the authoring session for a second requestorbeing an attachment to the authoring session for authoring thedeclarative document.
 4. The method in accordance with claim 3, theallowance of the request for the first requestor to establish theauthoring session comprising causing a document server host to be hostedat a particular network address, and registering the network addresswith a distributed redistribution service.
 5. The method in accordancewith claim 4, the allowance of the request for the second requestor toattach to the authoring session comprising registering the secondrequestor with the distributed redistribution service.
 6. The method inaccordance with claim 2, the allowance of the request for the firstrequestor to establish the authoring session comprising causing adocument server host to be hosted at a particular network address, andregistering the network address with a distributed redistributionservice.
 7. The method in accordance with claim 6, the registering ofthe network address with the distributed redistribution service furthercomprising registering a version of the document server host to beregistered with the distributed redistribution service.
 8. The method inaccordance with claim 1, the allowing the requested engagement in theauthoring session in which the declarative document is authoredcomprising: determining a network address of a document server host thathost the authoring session; and routing the request to the networkaddress.
 9. The method in accordance with claim 1, the allowing therequested engagement in the authoring session in which the declarationdocument is authored comprising: identifying a version of the documentserver host associated with the request; determining a network addressof a document server host of that identified version that that hosts theauthoring session; and routing the request to the network address. 10.The method in accordance with claim 1, at least one of the accessed jobtokens authoring its holder to share authorization to engage in theauthoring session.
 11. A computing system that receives a plurality ofrequests to engage in an authoring session in which a declarativedocument is authored for compilation into an executable application, atleast some of the requests for engagement being from differentrequestors, the plurality of requests collectively including a pluralityof job tokens that define authorization scope in engaging with thesession in which the declarative document is authored, the plurality ofjob tokens generated so that concurrent authoring of the declarativedocument is achieved in the session without inconsistent activity on thedeclarative document, the computing system comprising: one or moreprocessors; and one or more computer-readable media having thereoncomputer-executable instructions that are structured such that, whenexecuted by the one or more processors, the computing system isconfigured to perform the following for at least one request forengagement received from each different requestor, performing thefollowing: accessing a job token associated with the request forengagement in the session in which the declarative document is authored;determining whether the requestor is authorized to engage in therequested engagement based on evaluation of the job token; if the useris not authorized based on this determination, decline the requestedengagement in the session in which the declarative document is authored;and if the user is authorized based on this determination, allowing therequested engagement in the session in which the declarative document isauthored.
 12. The computing system in accordance with claim 1, theengagement in the authoring session for a first requestor being anestablishment of the authoring session for authoring the declarativedocument.
 13. The computing system in accordance with claim 12, theengagement in the authoring session for a second requestor being anattachment to the authoring session for authoring the declarativedocument.
 14. The computing system in accordance with claim 13, theallowance of the request for the first requestor to establish theauthoring session comprising causing a document server host to be hostedat a particular network address, and registering the network addresswith a distributed redistribution service.
 15. The computing system inaccordance with claim 14, the allowance of the request for the secondrequestor to attach to the authoring session comprising registering thesecond requestor with the distributed redistribution service.
 16. Thecomputing system in accordance with claim 12, the allowance of therequest for the first requestor to establish the authoring sessioncomprising causing a document server host to be hosted at a particularnetwork address, and registering the network address with a distributedredistribution service.
 17. The computing system in accordance withclaim 16, the registering of the network address with the distributedredistribution service further comprising registering a version of thedocument server host to be registered with the distributedredistribution service.
 18. The computing system in accordance withclaim 11, the allowing the requested engagement in the authoring sessionin which the declarative document is authored comprising: determining anetwork address of a document server host that host the authoringsession; and routing the request to the network address.
 19. Thecomputing system in accordance with claim 11, the allowing the requestedengagement in the authoring session in which the declaration document isauthored comprising: identifying a version of the document server hostassociated with the request; determining a network address of a documentserver host of that identified version that that hosts the authoringsession; and routing the request to the network address.
 20. A computerprogram product comprising one or more computer-readable storage mediahaving thereon computer-executable instructions that are structured suchthat, when executed by one or more processors of a computing system, thecomputing system is caused to perform a method for managing an authoringsession in which a declarative document is being authored forcompilation into an executable application, wherein as part of theauthoring session, the computing system receives a plurality of requeststo engage in an authoring session in which a declarative document isauthored for compilation into an executable application, at least someof the requests for engagement being from different requestors, theplurality of requests collectively including a plurality of job tokensthat define authorization scope in engaging with the session in whichthe declarative document is authored, the plurality of job tokensgenerated so that concurrent authoring of the declarative document isachieved in the session without inconsistent activity on the declarativedocument, the method comprising the following for at least one requestfor engagement received from each different requestor, performing thefollowing: accessing a job token associated with the request forengagement in the session in which the declarative document is authored;determining whether the requestor is authorized to engage in therequested engagement based on evaluation of the job token; if the useris not authorized based on this determination, decline the requestedengagement in the session in which the declarative document is authored;and if the user is authorized based on this determination, allowing therequested engagement in the session in which the declarative document isauthored.